							January 24, 1995


      This is the README file of the distribution of AliBaba. AliBaba is a
      test platform for the effect of the use of transposition tables in
      combination with alpha-beta search. The complete distribution can be
      obtained by anonymous ftp as follows:

			 ftp ftp.cs.rulimburg.nl
			 Name: anonymous
			 Password: <your email-address>
			 cd pub/software/breuker
			 bin
			 get alibaba.tar.Z
			 quit
			 uncompress alibaba.tar.Z
			 tar xvf alibaba.tar


1.INTRODUCTION
--------------

This file belongs to the program AliBaba. AliBaba is a simple chess program
used for testing several search techniques. The results of experiments
with replacement schemes for transposition tables are to be found in
Breuker, Uiterwijk and Van den Herik (1994) (see section 7).
AliBaba can be compiled on Unix-machines (gcc), or PC's (Watcom 9.5
or bcc 3.1), ALTHOUGH I HAVEN'T TESTED THE LATTER TWO THOROUGHLY.

In section 2, the files of this distribution are listed. In AliBaba,
the search techniques can be incorporated through parameter options.
These options are described in section 3. AliBaba can be run
automatically (when using one of the parameter options -test, -color,
-depth, -nodes) or interactively (otherwise). In interactive mode,
several commands are available. They are given in section 4. In
section 5 the format of a saved position is described. The output
of AliBaba is explained in section 6. Paragraph 7 lists the reference
mentioned in this file.


2.NECESSARY FILES
-----------------

. Source code:
    ab.c, command.c, diskio.c, evaluate.c, generate.c, init.c, io.c, main.c,
    move.c, quies.c, search.c, testing.c, var.c,
    const.h, macro.h, type.h, var.h.
. Makefile:
    Makefile, watcom.mak, ab.prj
  Makefile is the file necessary for the gcc-compiler on Unix-machines.
  watcom.mak is the makefile necessary for the Watcom 9.5 compiler on PC's.
  ab.prj is the project-file necessary for the bcc 3.1 compiler on PC's.
. Random values needed for calculation of hash value:
    random.tab
  This file is needed to let AliBaba always have the same results. If
  different random values are used, different collisions will occur,
  and therefore a different number of nodes will be investigated.
  This distribution contains two of these files: little.tab and
  big.tab. little.tab is voor little-endian machines (PC's) and
  big.tab is for big-endian machines (SUN's). ONLY ONE OF THESE FILES
  IS NECESSARY! Choose the one which is necessary for your machine,
  and copy it to the file random.tab.
. Machine-dependent file:
    compiler.def
  This file contains the definitions for signed and unsigned values for
  numbers consisting of 1, 2 and 4 bytes. Furthermore, it contains
  definitions which compiler is used: Gcc (Gnu C ), Bcc (Borland C),
  or Watcom (Watcom C). The last two are compilers for PC.
  This distribution contains three of these files: gcc.def, bcc.def and
  watcom.def. ONLY ONE OF THESE FILES IS NECESSARY! Choose the one which 
  is necessary for your machine/compiler and copy it to the file compiler.def.
. Ascii version of all results of Breuker, Uiterwijk and Van den Herik (1994):
    tables.txt
  This file contains more data than in Appendix B of the article. It contains
  all 3-ply to 8-ply search results for table sizes of 8K to 1024K positions.
. This file:
    README


3.PARAMETER OPTIONS
-------------------

The following options can be used when starting the program. Every option is
followed by an example. The DEFAULT describes what happens if the option is 
*not* invoked.

-file <filename>
  <filename> is a string (without quotes) denoting a filename.
  This file is loaded from the subdirectory "games", and will be the
  starting position. The format of a gamefile will be described later.
  . EXAMPLE: ab -file kasparov.001
      loads the file "games/kasparov.001"
  . DEFAULT: AliBaba starts in the starting position.

-test <move number>
  <move number> is an integer. When this option is invoked, AliBaba searches
  the present game from move <move number> onwards for one side to move.
  This is a nice way of automatically testing AliBaba on consecutive 
  positions with the same side to move.
  . EXAMPLE: ab -file kasparov.001 -test 10
      loads the file "games/kasparov.001" and starts searching from move 10
      onwards.
  . DEFAULT: AliBaba only searches the current position.

-color <color>
  <color> is either white or black. AliBaba examines position(s) with this
  side to move.
  . EXAMPLE: ab -color white
      searches the starting position for the white side.
  . DEFAULT: white

-depth <depth>
  <depth> is an integer, denoting the ply-depth that AliBaba must search to.
  . EXAMPLE: ab -depth 3
      searches the starting position for 3 ply.
  . DEFAULT: 5

-nodes <number of nodes>
  <number of nodes> is an integer, denoting the number of nodes AliBaba
  must search for. If this number is reached, the search is terminated 
  after the examination of the current move is finished. Therefore,
  slightly more nodes will be examined.
  . EXAMPLE: ab -nodes 100
      searches the starting position for slightly more than 100 nodes.
  . DEFAULT: infinity.

-transpos [0|1]
  This denotes whether the a transposition table needs to be used.
  . EXAMPLE: ab -transpos 0
      searches without a transposition table.
  . DEFAULT: 1

-refs [0|1]
  This denotes whether a refutation table needs to be used.
  . EXAMPLE: ab -refs 1
      searches with a refutation table.
  . DEFAULT: 1

-ttBits <number of bits>
  <number of bits> is an integer, denoting the number of bits of the
  hash index. The size of the hash table is 2^<number of bits> positions.
  . EXAMPLE: ab -ttBits 16
      uses a transposition table with 65536 (2^16) positions.
  . DEFAULT: 19

-keepPly <ply>
  <ply> is an integer, denoting the number of ply a position is to be kept
  in the transposition table. If a position is older than <ply> ply, it
  is either removed or timeStamped (depending on -timeStamp).
  . EXAMPLE: ab -keepPly 0
      clears (or time stamps) the transposition table after every move in
      the game.
  . DEFAULT: 0

-scheme <scheme>
  <scheme> is a string (without quotes), denoting which replacement scheme
  to use in case of a collision. <scheme> can be one of the following:
  old:
    in case of a collision, the oldest position is kept in the table. Thus,
    a position is *never* overwritten.
  new:
    in case of a collision, the newest position is kept in the table. Thus,
    a position is *always* overwritten.
  deep:
    in case of a collision, the position with the deepest subtree is kept
    in the table
  big1:
    in case of a collision, the position with the biggest subtree (in terms
    of number of nodes) is kept in the table. A position read from the
    transposition table is counted as one node.
  bigAll:
    in case of a collision, the position with the biggest subtree (in terms
    of number of nodes) is kept in the table. A position read from the
    transposition table is counted as the number of nodes it had been searched
    for.
  . EXAMPLE: ab -scheme new
      always replaces a position in case of a collision.
  . DEFAULT: big1

-table [1|2]
  This denotes whether the transposition table is a one-level table or a
  two-level table. A one-level table is a table with one position per entry.
  A two-level table is a table with two positions per entry. If a two-level
  table is used, only schemes deep, big1 and bigAll can be used. The two
  positions which are stored are the newest position and the most important
  position (denoted by -scheme).
  . EXAMPLE: ab -scheme deep -table 2
      uses a two-level deep transposition table (termed TwoDeep in
      Breuker, Uiterwijk and Van den Herik (1994)).
  . DEFAULT: 2

-ttValue [0|1]
  This denotes whether the value read from the transposition table is
  used.
  . EXAMPLE: ab -ttValue 0
      does not use the value when a position is found in the transposition
      table.
  . DEFAULT: 1

-ttMove [0|1]
  This denotes whether the move read from the transposition table is
  used.
  . EXAMPLE: ab -ttMove 0
      does not use the move when a position is found in the transposition
      table.
  . DEFAULT: 1

-timeStamp [0|1]
  This denotes whether an entry in the table which is outdated (defined by
  -keepPly) should be time stamped or should be cleared.
  . EXAMPLE: ab -keepPly 0 -timeStamp 0
      clears entries in the transposition table after every move in the game.
  . DEFAULT: 1


4.INTERACTIVE COMMANDS
----------------------

When in interactive mode, AliBaba knows the following commands:
help, move, printboard, list, forward, back, new, printgame, compute,
save, load, clear, place, remove, quit. To get more information
about the commands, type help when in interactive mode.


5.FORMAT OF GAMEFILE
--------------------

A gamefile consists of
. comment:
    A line starting with the %-sign is skipped completely.
. position:
    This is optional. If no position is present, the starting position is
    chosen. A position consists of three lines:
    1. white pieces
      Just type the first character of a piece, followed by a square.
      Pieces are seperated by one ore more spaces.
    2. black pieces
    3. side to move, en passant and castling information.
      The side to move is either WTM (white), or BTM (black)
      The en passant square is optional
      The castling information is also optional. The default is no castling.
      If castling is possible it can be denoted by WL (white long castling
      is possible), WS (white short), BS and/or BL. Again, everything
      seperated by spaces.
. moves:
    This is also optional. Note, however, that at least a position or moves
    should be present in a game. Moves are given in long algebraic notation.
  . EXAMPLE:
  % This is an example game file
  % White pieces
  Ke1 Rh1 e2 f2 g2 h2
  % Black pieces
  Ke8 Ra8 b7 c7 d7 e7
  % White to move, White short castling is still possible
  WTM WS
  % The following moves have been played from this position:
  e2-e4 Ra8-a2 0-0
  % This is the end of the file.


6.PROGRAM OUTPUT
----------------

Here follows an example output. In the first column the ply number AliBaba
searches to is given. In the second column, the total search time (in seconds)
is given when the variation is printed. In the third column the value of
the variation is given (the value of a pawn is 1.000). >> means that a fail
high has occurred, while << means that a fail low has occurred. Hereafter
the best variation is given. Moves after a dot in the variation are moves
from quiescence search. After this variation a number is given, denoting
the ply depth of the given variation.
At the end of the search two lines of information are given. The first line
denotes nunber of nodes searched (all nodes in the tree are counted),
number of internal, leaf and quiescence nodes and number of nodes per second.
The second line describes how many moves have been generated at how
many nodes. The number between parentheses is the mean number of moves per
position.

 1     0.02s  -6.770 Rf1xf2  .Qb6xf2                                 2
       0.03s     >>  Kh1-g1                                          1
       0.03s  -5.060 Kh1-g1                                          1
====================[ 0.03 ]====================
 2     0.05s  -5.110 Kh1-g1  Nf2-d3  .Kg1-h1                         3
====================[ 0.05 ]====================
 3     0.08s  -5.110 Kh1-g1  Nf2-d3  Kg1-h1                          3
====================[ 0.08 ]====================
 4     0.25s  -5.220 Kh1-g1  Nf2-d3  Kg1-h1  Qb6-d4                  4
====================[ 0.27 ]====================
 5     0.95s  -5.130 Kh1-g1  Nf2-d3  Kg1-h1  Qb6-d4  Rf1-f5          5
====================[ 0.95 ]====================
 6     1.70s     <<  Kh1-g1  Nf2-h3  Kg1-h1  Qb6-g1  Rf1xg1  Nh3-f2  6
       5.83s -Mate03 Kh1-g1  Nf2-h3  Kg1-h1  Qb6-g1  Rf1xg1  Nh3-f2  6
====================[ 6.55 ]====================
--> Best value loses, stop searching
33775 nodes (int:8534, leaf:25241, quies:5420), 5156 n/s
52752 moves in 2992 times (17.63)


7.REFERENCE
-----------

D.M. Breuker, J.W.H.M. Uiterwijk and H.J. van den Herik (1994).
Replacement Schemes for Transposition Tables.
ICCA Journal, Vol. 17, No. 4, pp. 183-193.

     A PostScript version of this article can be obtained by anonymous ftp
     as follows:

			 ftp ftp.cs.rulimburg.nl
			 Name: anonymous
			 Password: <your email-address>
			 cd pub/papers/breuker
			 bin
			 get schemes.ps.Z
			 quit
			 uncompress schemes.ps.Z
			 lpr schemes.ps


Dennis Breuker
_____________________________________________________________________________
 http://www.cs.rulimburg.nl/~breuker               | breuker@cs.rulimburg.nl
 Dept. of computer science, University of Limburg  | Voice: +31.43.883379
 P.O. Box 616, 6200 MD Maastricht, The Netherlands | Fax  : +31.43.252392
